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Date Pamela Gerik 



SUPPLEMENTAL APPEAL BRIEF 

Sir: 

Further to the Notice of Appeal faxed September 24, 2004 and received in the U.S. Patent 
and Trademark Office on the same day, Appellant presents this Supplemental Appeal Brief. 
This supplemental brief is filed in response to a Notice of Non-Compliant Brief mailed October 
17, 2006. The Notice of Appeal was filed following mailing of a Final Office Action on June 30, 
2004. Appellant hereby appeals to the Board of Patent Appeals and Interferences from a final 
rejection of claims 1-25 in the Final Office Action, and respectfully requests that this appeal be 
considered by the Board. 

I. REAL PARTY IN INTEREST 

The subject application is owned by International Business Machines Corporation, a 
corporation having its principal place of business at New Orchard Road, Armonk, New York, 
10504, as evidenced by the assignment recorded at Reel 01 1888, Frame 0379. 
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II. RELATED APPEALS AND INTERFERENCES 

Notices of Appeal have been filed for the following applications, which share a common 
specification with the application currently on appeal. 



09/870,613: Notice of Appeal filed 2/07/05: 
09/870,615: Notice of Appeal filed 9/14/04: 
09/870,620: Notice of Appeal filed 12/7/04: 
09/870,621: Notice of Appeal filed 9/24/04: 
09/870,622: Notice of Appeal filed 8/24/04: 
09/870,624: Notice of Appeal filed 5/23/05: 



Appeal Brief filed April 7, 2005. 
Appeal Brief filed November 9, 2004. 
Appeal Brief filed February 7, 2005. 
Appeal Brief filed November 23, 2004. 
Appeal Brief filed October 25, 2004. 
Appeal Brief filed July 25, 2005. 



However, because dissimilar art is cited in the present application and the above-mentioned 
related applications, Appellants do not believe that the outcome of this appeal will have any 
bearing on the Board's decision on the related appeals. No other appeals or interferences are 
known which would directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 



III. 



STATUS OF CLAIMS 



Claims 1-25 are pending in the captioned case. Claims 1-25 stand rejected. 



IV. STATUS OF AMENDMENTS 



No amendments to the claims have been filed subsequent to their final rejection. The 
Appendix hereto therefore reflects the current state of the claims. 
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V. 



SUMMARY OF CLAIMED SUBJECT MATTER 



Appellant's claimed invention relates to a system of software components (172, 174 and 
176, Fig. 17), a computer-readable storage device (18, Fig. 1) and a method (Fig. 18) for 
dynamically switching between two proxy components (174, 176, Fig. 17), depending on a mode 
of use of an object (170) displayed in a graphical user interface (GUI). (See, Specification — 
page 38, line 17 to page 40, line 6, and Abstract). 

In some embodiments, the system of software components as recited in claim 1 may be 
configured for displaying an object (170, Fig. 17) created by an application program (APP, Fig. 
1) running under an operating system (OS). (See, Specification — page 16, line 24 to page 17, 
line 2, and Fig. 1) In general, the system of software components may include a first proxy 
component (174), a second proxy component (176), and a peer component (172). The peer 
component (172) may be used for selecting either the first proxy component (174) or the second 
proxy component (176), depending on a mode of use of the object (170). After a proxy 
component is selected, the selected proxy component may dynamically create a new graphics 
resource component for displaying the object in a manner, which is independent of the operating 
system. (See, Specification — page 39, lines 7-14, Abstract and Fig. 17) 

In particular aspect of the claimed invention, the system of software components (172, 
174 and 176, Fig. 17) provides a unique mode-switching capability, which permits two Swing 
objects (e.g., the JTextField and JPasswordField components) to alternate as replacements for an 
AWT object (e.g., the TextField component), depending on the manner in which the AWT object 
is being used by the application program. In one example, selection between the first and second 
proxy components may depend on the status of an echo character, which specifies whether 
entered text should be displayed as masked (e.g., "*****") 0 r unmasked (e.g., "hello") text. 
(See, Specification — page 39, lines 10-14) If a legacy application (APP 28, Fig. 1) is using an 
AWT TextField (170, Fig. 17) without password protection, no echo character is set. This 
causes the peer component (JTextFieldPeer 172) to select the first proxy component 
(JTextFieldProxy 174), which creates a new graphics resource component (e.g., a Swing 
JTextField component) for displaying the AWT TextField object without password protection. 
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(See, Specification — page 39, lines 14-16) If an echo character is set, however, the peer 
component (JTextFieldPeer 172) selects the second proxy component (JPasswordFieldProxy 
176), which creates a new graphics resource component (e.g., a Swing JPasswordField 
component) for displaying the AWT TextField object with password protection. (See, 
Specification — page 39, lines 16-19) In either case, the newly created graphics resource 
component displays the object in a manner, which is independent of the operating system. (See, 
Specification - page 39, lines 19-25) 

In some embodiments, the method (Fig. 18) as recited in claim 13 may be configured for 
displaying an object (170, Fig. 17) created by an application program (APP, Fig. 1) running 
under an operating system (OS). (See, Specification - page 16, line 24 to page 17, line 2 and 
Fig. 1) In particular, the method may use at least one of a system of software components (e.g., 
172, 174 or 176, Fig. 17), which can be invoked during runtime to generate a graphical 
representation of the object. As noted above, the graphical representation of the object is 
substantially independent of the operating system. (See, Specification - page 39, lines 7-14, 
Abstract and Figs. 1 and 17) 

In particular, the method (Fig. 18) performed by the application program may include the 
steps of: activating a first proxy component (e.g., JTextFieldProxy 174, Fig. 17) of the system of 
software components to dynamically generate a first graphical representation of the object (e.g., 
a Text Field box) during runtime. (See, Specification — page 39, lines 27-28) Next, the method 
may monitor the mode of use of the object. For example, the method may monitor the status of 
an echo character to determine if there has been a change in status (178, Fig. 18). (See, 
Specification - page 39, lines 28-29) Upon detecting a change in the mode of use of the object 
(yes branch of 178), the method may deactivate (180, 182) the first proxy component and 
activate (184, 186, 188) a second proxy component (e.g., JPasswordFieldProxy 176, Fig. 17) of 
the system of software components to dynamically generate a second graphical representation of 
the object (e.g., a Password Field box) during runtime. (See, Specification — page 40, lines 1-6). 
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In some embodiments, the computer-readable storage device (18, Fig. 1) as recited in 
claim 25 may include a windows-based operating system (OS), an application program (APP) 
running under the operating system, and an object (170, Fig. 17) created at runtime by the 
application program and adapted for multiple modes of use by the application program. (See, 
Specification — page 16, line 24 to page 17, line 2 and Fig. 1) In a particular embodiment, the 
"multiple modes of use" may correspond to the use of a text field as either a normal Text Field, 
which displays unmasked text, or a Password Text Field, which displays masked text. (See, 
Specification — page 38, line 17 to page 39, line 25) In any case, the application program may 
be adapted for performing the method steps described above and shown in Figs. 17 and 18. (See, 
Specification — page 39, line 27 to page 40, line 6). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1 . Claims 1-25 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over WinZip 
computing Inc., WINZIP 8.0 (hereinafter "WinZip"), in view of the publication referred 
to as Java Platform 1 .2 Beta 4 API Specification: Class JPasswordField and Class 
JTextField (hereinafter "Java"), and in further view of U.S. Patent No. 5,327,529 to Fults 
et al. (hereinafter "Fults"). 

VII. ARGUMENT 

The contentions of the Appellant with respect to the ground of rejection presented for 
review, and the basis thereof, with citations of the statutes, regulations, authorities, and parts of 
the record relied upon are presented herein for consideration by the Board. Details as to why the 
rejections cannot be sustained are set forth below. 

A. Patentability of claims 1-25 under 35 U.S.C $ 103(a) 

Claims 1-25 were rejected under 35 U.S.C. § 103(a) as being unpatentable over WinZip, 
Java and Fults. As described in more detail below, the § 103(a) rejection of claims 1-25 is hereby 
traversed. 
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MPEP 2143 establishes the basic requirements in finding a prima facie case of 
obviousness. As described, to establish a case of prima facie obviousness of a claimed 
invention, three criteria must be met. First, there must be some suggestion or motivation, either 
in the references themselves or in the knowledge generally available to one of ordinary skill in 
the art to modify the references or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art references must teach or suggest all the 
claim limitations. Specifically, "all words in a claim must be considered when judging the 
patentability of that claim against the prior art." In re Wilson 424 F.2d. 1382, 1385 (CCPA 
1970). If an independent claim is nonobvious under 35 U.S.C. 103, then any claim depending 
therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988). 

1. Patentability of claims 1-12 under 35 U.S.C $ 103(a) 

None of the cited art teaches or suggests a system of software components including 
a first proxy component, a second proxy component and a peer component for displaying 
an object, where the peer component is configured for selecting, during runtime, either the 
first proxy component or the second proxy component, depending on a mode of use of the 
object, as recited in claim 1. Independent claim 1 states in part: 

A system of software components adapted to display an object . . . wherein the 
system of software components comprises: a first proxy component; a second 
proxy component; and a peer component for selecting either the first proxy 
component or the second proxy component, depending on a mode of use of the 
object, wherein the selection can be made during runtime, and wherein the 
selected proxy component thereafter creates a new graphics resource component 
for displaying the object, such that the appearance of the displayed object is 
substantially independent of the operating system. 

In general, the presently claimed case provides a unique system of software components that 
enables an application program (e.g., a Java application) to be truly portable across all operating 
system (OS) platforms by providing various means for maintaining the "look and feel" of the 
application program. "A software program is said to be 'portable' across various platforms if the 
program can run without modification on any of those platforms." (Specification — page 6, lines 
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23-24, emphasis added). Before disclosing such means, the specification highlights several 
drawbacks of prior art attempts at application portability. 

For example, Java application programs utilize a platform-dependent application program 
interface (API), commonly known as the Abstract Windowing Toolkit (AWT), to produce 
heavyweight software components that are written in native code (i.e., instructions specific to a 
particular OS). When AWT heavyweight software components are used for displaying images, 
the "look and feel" of those images may differ depending on the particular OS running the Java 
application program. In the context of a graphical user interface (GUI), "the 'look and feel' of a 
GUI refers to such things as the appearance, color and behavior of Buttons, TextFields, 
Listboxes, menus, etc. . ." (Specification — page 7, line 4-8). Thus, there are certain limitations 
within the AWT that prohibit true portability of Java application programs, especially in terms of 
the look and feel of the application program. See, e.g., Specification — page 7, line 24 to page 9, 
line 10, and page 18, line 10 to page 19, line 23. 

In an effort to overcome the platform-dependency of AWT -based programs, Swing was 
developed as part of the Java Foundation Classes (JFC). An API written using Swing contains 
no native code, and therefore, can be run on substantially any OS without changing the look and 
feel of the application. See, e.g., Specification - page 9, lines 14-30, and page 19, line 25 to 
page 20, line 4. Unfortunately, the lightweight software components of Swing cannot 
completely eliminate the platform-dependency of Java applications that use AWT. Since Swing 
versions of many AWT components (e.g., containers, such as frames) are unavailable, many 
programmers have attempted to mix Swing and AWT components within a given API. See, e.g., 
Specification — page 21, lines 1-13. However, straightforward mixing of Swing and AWT 
components tends to create many problems that programmers have simply learned to accept. 
See, e.g., Specification — page 22, lines 1-28. 

One problem encountered when mixing Swing and AWT components within a given API 
arises when programmers attempt to replace the dual-mode, AWT TextField component with a 
lightweight Swing counterpart. In AWT, the functionalities of a normal text field and a 
password-protected text field are both included within the AWT TextField component. 
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However, the normal and password-protected functionalities are not included within a single 
Swing component, but instead, are separately allocated to the Swing JTextField and 
JPasswordField components. If a Java application program originally displays an object using 
the AWT TextField component, the behavior of that program cannot be maintained by simply 
replacing the AWT TextField component with a single Swing component. See, e.g., 
Specification — page 38, line 17 - page 39, line 5. 

In order to utilize Swing components, while maintaining behavioral compatibility with 
the Java application program, the present inventors recognized that the appropriate Swing 
component must be dynamically recreated and substituted for the AWT component each time the 
mode of use of the object changes. This is in direct contrast to the manner in which Swing 
components are normally created (i.e., during the initial construction of the peer component). 
See, e.g., Specification — page 39, lines 7-8. 

Therefore, the presently claimed case provides a system of software components for 
overcoming one of the many problems that occurs when programmers attempt to mix AWT and 
Swing components within a Java application program. In general, the presently claimed system 
of software components - referred to as "AWTSwing" components - enable an object to be 
displayed using one of two different Swing software components, which are dynamically created 
at runtime depending on a mode of use of the object . In other words, the presently claimed 
system of software components provides a unique mode-switching capability that allows two 
Swing software components to alternate as replacements for an AWT software component, 
depending on the manner in which the object is being used. See, e.g., Specification - page 38, 
line 17 - page 40, line 6. 

To provide mode-switching capability, the system of software components includes a 
first proxy component (JTextFieldProxy 174), a second proxy component (JPasswordFieldProxy 
176) and a peer component (JTextFieldPeer 172), as shown in Fig. 17. As used herein, the term 
"software component" may be defined as "any sequence of executable code." (Specification — 
page 3, line 16). As such, a "proxy component" may be generally defined as a sequence of 
executable code that, when executed, (i) translates the method calls from an AWT component to 
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the appropriate Swing component, and (ii) translates the event calls from a Swing component to 
the AWT component (e.g., a frame) containing the Swing component. As used by the proxy 
component, a "method call" may be defined as a get routine to another software component (e.g., 
a "graphics resource component") that creates and manipulates a graphical representation of the 
object to therefore display the object. See, e.g., Specification — page 23, lines 16-18; page 29, 
lines 7-10. 

In present claim 1, the "peer component" is used for selecting either the first proxy 
component or the second proxy component, depending on a mode of use of the object . In the 
context of a Text Field box, the "mode of use" may correspond to whether text entered into the 
box is to be displayed with masked (e.g., "*****") 0 r unmasked (e.g., "hello") text. Once 
selected by the peer component, the selected proxy component will create a new graphics 
resource component (e.g., a Swing JTextField or JPasswordField software component) for 
displaying the object. Since the object is displayed with a Swing component, rather than an 
AWT component, the appearance of the displayed object will be substantially independent of the 
operating system running the Java application program. In other words, the properties that 
define the "look and feel" of the object (e.g., the color, position, text, etc.) will not be affected by 
the operating system running the Java application program. 

As described in more detail below, none of the cited art, either separately or in 
combination, provides motivation to teach or suggest a system of software components for 
selecting, during runtime, a first proxy component or a second proxy component for use in 
displaying an object, where the selection is dependent on a mode of use of the object and where 
the appearance of the displayed object is substantially independent of the operating system. 
Therefore, the teachings of the cited art cannot be used to render the limitations of the presently 
claimed case unpatentable. 

As noted in the Response to the Office Action Mailed January 15, 2004, neither WinZip 
nor Java, either separately or in combination, can be used to teach or suggest the presently 
claimed system of software components. For example, the screen shots provided on pages 3 and 
4 of the WinZip reference can only be used to show how various objects (e.g., frames, dialog 
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boxes, buttons, check boxes, text boxes, etc.) may be displayed when the "Mask password" 
checkbox is toggled between unchecked (page 3) and checked (page 4). More specifically, the 
screen shots on pages 3 and 4 of the WinZip reference can only be used to show how the 
Password text box may display masked text ("*****") or unmasked text ("hello"), depending on 
a mode of use of the Password text box. 

However, the screen shots on pages 3 and 4 of the WinZip reference cannot be used to 
provide teaching or suggestion for the presently claimed system of software components, which 
as noted above, includes a first proxy component, a second proxy component and a peer 
component . Though the screen shots may show the end product (i.e., the WinZip GUI) obtained 
by the execution of one or more (inherently included) WinZip software components, the screen 
shots cannot provide insight into the particular software components (where "software 
components" are defined as sequences of executable code) that were used to produce the end 
product . The WinZip reference simply does not and cannot teach or suggest that the presently 
claimed software components — i.e., the first proxy component, the second proxy component and 
the peer component — are used for displaying the objects shown in the WinZip GUI. 

The WinZip reference also fails to provide inherent teaching or suggestion for the 
presently claimed system of software components. For example, the WinZip reference does not 
teach or suggest that the functionality shown in the screen shots (i.e., the alternation between 
masked and unmasked text in the Password text box) could be provided by software components 
similar to the presently claimed proxy and peer components. In other words, given the 
functionality disclosed in the screen shots on pages 3 and 4 of the WinZip reference, one skilled 
in the art could not reasonably conclude that a first proxy component, a second proxy component 
and a peer component (or equivalent software components demonstrating the presently claimed 
functionality) would necessarily be included to provide such functionality. 

First of all, the WinZip reference fails to disclose the programming language used to 
produce the WinZip GUI. The Applicant concedes that one skilled in the art may assume that an 
object-oriented programming (OOP) language was used to construct the software components 
needed to produce the WinZip GUI, simply because such languages are typically used in 
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developing GUIs. Thus, for the sake of argument, we may assume that the WinZip screen shots 
are produced by one or more software components written purely in the Java programming 
language (a popular OOP language, and therefore, a reasonable assumption). After making such 
an assumption, one skilled in the art may also assume that a Java peer component (e.g., the 
heavyweight AWT TextComponentPeer) and a Java graphics resource component (e.g., the 
heavyweight AWT TextField) are included within the WinZip software components. If this is 
the case, the Java peer component could invoke the methods of the Java graphics resource 
component, which would then display the object. However, the appearance of the displayed 
object would not be independent of the operating system, as in the presently claimed case, 
because a heavyweight graphics resource component (containing native code) would be used for 
displaying the object in the WinZip GUI. Furthermore, since the methods for displaying text as 
either masked or unmasked are both provided within the existing Java graphics resource 
component (e.g., within the AWT TextField component), the Java peer component would have 
no need for selecting between a first proxy component and a second proxy component. In fact, if 
the WinZip software components were written purely in Java, there would be no need for 
including proxy components that, when selected by the peer component, function to dynamically 
create new graphics resource components for displaying the object. Thus, if one were to assume 
that the WinZip software components were written purely in Java, the WinZip software 
components would not include the first proxy component, second proxy component and peer 
component, as recited in present claim 1 . 

In addition, the Java reference cannot be combined with the WinZip reference to 
overcome the deficiencies therein. For example, the Java reference fails to provide teaching or 
suggestion for a first proxy component, a second proxy component and a peer component for 
selecting between the first and second proxy components, depending on a mode of use of an 
object. Since WinZip and Java each fail to teach or suggest the presently claimed system of 
software components, the cited art cannot be combined to do so. 

Even if one were to make the combination proposed by the Examiner (without sufficient 
motivation to do so), the proposed combination would still fail to disclose all limitations of 
present claim 1 . Lets assume, for example, that a programmer wishes to replace the above - 
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mentioned Java graphics resource component (e.g., the heavyweight AWT TextField) with a 
Swing graphics resource component, i.e., a lightweight software component. If the programmer 
attempted to make such a replacement, he/she would run into several problems. 

First of all, the Java graphics resource component may have combined features (e.g., 
masked and unmasked text capabilities) that simply do not exist within a single Swing graphics 
resource component . Therefore, the programmer could not directly replace the Java component 
with an equivalent Swing component (since none exists). Even if the programmer were to 
replace the Java graphics resource component with multiple Swing graphics resource 
components (e.g., by modifying the existing Java peer component to invoke the methods of the 
Swing, rather than the AWT, graphics resource components), the replacement Swing 
components would not behave properly (e.g., they would not respond to action events, such as 
mouse clicks or keyboard entries), since the replacement Swing components would not be 
declared as contained within a Frame of the Java application program. See, e.g., Specification — 
page 22, lines 23-28. 

In addition, one skilled in the art would not consider the presently claimed proxy 
components to be an obvious feature in light of the WinZip and Java references. For example, 
Swing components are normally created only during the initial construction of the peer 
component (See, e.g., Specification page 39, lines 7-25). Therefore, one skilled in the art would 
not consider the dynamic creation of Swing components to be an obvious feature. As a 
consequence, the presently claimed proxy components (which dynamically create the 
appropriate Swing component during runtime) cannot be considered obvious features in light of 
the WinZip and Java references. 

The arguments provided above clearly show how the WinZip and Java references fail to 
teach or suggest a first proxy component, a second proxy component and a peer component for 
selecting either the first or second proxy component, depending on a mode of use of an object. 
On page 3 of the final Office Action, the Examiner admits that "WinZip and Java . . . don't teach 
using a peer component for selection between two proxy components." Applicants appreciate 
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the Examiner's recognition of any lack of teaching within WinZip and Java for the presently 
claimed software components. 

However, the Examiner suggests that "Fults teaches a system which generates [a user] 
interface based on a selection by the user (see column 3, lines 27-52) similar to that of WinZip 
and Java ..." (Final Office Action, page 3). The Examiner suggests that Fults "further teaches 
taking hints from a user and using the hints to direct the interface generation to an appropriate 
user interface implementation (see column 3, lines 33-51, figure 2, and the abstract)" (Final 
Office Action, page 3). Applicants respectfully disagree with the Examiner's alleged evidence 
of teaching within Fults for the presently claimed peer and proxy components. Reasons 
supporting why the teachings of Fults fail to mention the presently claimed software components 
are set forth in more detail below. 

For example, pointing out that Fults "teaches taking hints from a user and using the hints 
to direct the interface generation to an appropriate user interface implementation" does not 
provide evidence of any teaching within Fults for the system of software components recited in 
present claim 1 . In other words, Fults does not teach or suggest a peer component for displaying 
an object by selecting either a first or second proxy component, depending on a mode of use of 
the object . 

Any selection between software components that may or may not be disclosed by Fults is 
not dependent on a mode of use of an object. Instead, Fults creates a generic user interface in the 
form of attributes and hints (provided by the programmer at the time of code generation) that 
may be used to produce a user interface, "which visually and behaviorally conforms to the 
explicit and implicit guidelines of a particular style guide." (See, e.g., Fults — column 9, line 55 
- column 10, line 26; column 15, line 62 - column 16, line 16). In other words, Fults discloses 
that an "application simply defines its user interface using a generic model . . . [o]nce the 
application's user interface is described in generic terms, the [invention of Fults] maps each 
generic UI object to one or more specific UI objects, depending on which specific user interface 
[i.e., particular style guide] is chosen." (See, e.g., Fults — column 16, lines 27-45; column 17, 
lines 21-25). "For example, an application's UI file might specify that a list of options be 
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presented to the user. Depending on the attributes and 'hints' of the generic object, this might be 
implemented as a submenu in OpenLook or as a dialog box in OSF/Motif T m." (Fults — column 
16, lines 45-50). Therefore, Fults discloses a generic user interface, whose objects (e.g., a list of 
options) may adopt a particular look and feel (e.g., the list may be displayed as a submenu or 
dialog box), depending on the "hints" provided by the programmer and the particular style guide 
(e.g., OpenLook or OSF/Motif T m) used to display the objects. However, the "hints" and "style 
guides" disclosed by Fults cannot be considered "modes of use." 

For example, "hints" are described by Fults as an "embodiment of human/computer 
interface criteria for an application, stored digitally. Examples of such criteria follow: 
'infrequently used feature,' 'advanced feature,' 'should be displayed as large as possible.'" 
(Fults, column 6, lines 2-8). Obviously, such "digitally stored criteria" cannot be considered a 
"mode of use of an object," as taught by the presently claimed case. In addition, "style guides" 
are described by Fults as a "document intended to impose visual and operational consistency 
across the set of applications running in a particular environment." (Fults — column 13, lines 1 
7-21). However, "style guides" (like OpenLook or OSF/Motif T m) are not "modes of use of an 
object," as taught in the presently claimed case. 

Therefore, even if Fults were to disclose a peer component for displaying an object by 
selecting either a first or a second proxy component (which he does not), the selection would not 
be dependent on a mode of use of the object . As a consequence, the teachings of Fults fail to 
disclose all limitations of the system of software components recited in present claim 1 . 

For at least the reasons set forth above, WinZip, Java and Fults each fail to teach or 
suggest all limitations of present claim 1 . 

There is no motivation to combine or modify the teachings of the cited art to 
provide a proxy component configured for displaying an object by selecting, during 
runtime, either a first or a second proxy component, depending on a mode of use of the 
object. To establish a case of prima facie obviousness of a claimed invention, all of the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 USPQ 
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580 (C.C.P.A 1974); MPEP 2143.03. Obviousness can only be established by combining or 
modifying the teachings of the prior art to produce the claimed invention where there is some 
teaching, suggestion, or motivation to do so. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 
(Fed.Cir. 1988); In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992); MPEP 2143.01. 

As noted above, WinZip, Java and Fults each fail to separately provide teaching or 
suggestion for the presently claimed peer and proxy components. In fact, the Examiner admits 
that "WinZip and Java. . . don't teach using a peer component for selection between two proxy 
components." (Final Office Action, page 3). However, the Examiner suggests that "[i]t would 
have been obvious to one of ordinary skill in the art, having the teachings of WinZip, Java, and 
Fults, before him at the time the invention was made to modify the password display system of 
WinZip and Java to be implemented with a peer component that directs the interface 
development to the appropriate user interface implementation. One would have been motivated 
to make such a combination because WinZip has a switch of display characteristics very similar 
to that of Fults, where upon a user selection, an element is displayed using a different API 
component." (Final Office Action, page 3). The Applicant's respectfully disagrees with the 
Examiner's motivation for combining the teachings of WinZip and Fults, and further asserts that 
neither WinZip nor Fults provide motivation to make such a combination. 

As noted above, the screen shots of WinZip can only be used to show how various 
objects (e.g., frames, dialog boxes, buttons, check boxes, text boxes, etc.) may be displayed in a 
graphical user interface (GUI) when the "Mask password" checkbox is toggled between 
unchecked (page 3) and checked (WinZip — page 4). Given the screen shots of WinZip, 
however, it is simply impossible to determine the software components used to realize the 
functionality shown therein. For example, the Applicants have theorized that the Java 
programming language could have been used to produce the WinZip GUI. According to such 
theory, the "switch of display characteristics" of WinZip (e.g., the switch between masked and 
unmasked text) may have been provided by the AWT TextField component. However, the 
screens shots of WinZip do not suggest, nor do they provide motivation for, implementing the 
"switch of display characteristics" with two different API components. Therefore, contrary to 
the Examiner's suggestion, the "switch of display characteristics" of WinZip are NOT 
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necessarily "similar to that of Fults, where upon a user selection, an element is displayed using a 
different API component." As a consequence, the Examiner's motivation for combining the 
teachings of WinZip and Fults is considered insufficient. 

Furthermore, WinZip and Fults cannot be combined to provide the presently claimed peer 
and proxy components, since neither WinZip nor Fults suggest the desirability of doing so. The 
mere fact that references can be combined or modified does not render the resultant combination 
obvious unless the prior art also suggests the desirability of the combination. In re Mills, 916 
F.2d 680, 16 USPQ2d 1430 (Fed. Cir. 1990); MPEP 2143.01. The invention of Fults provides a 
generic user interface, including attributes and hints, which can be interpreted during runtime to 
produce a user interface that conforms to the look and feel of a particular style guide. If there is 
any selection within Fults between two proxy components, such selection is based on the 
particular style guide used to display the GUI elements. Fults provides absolutely no desirability 
for selecting between two proxy components, depending on a mode of use of a displayed object. 
Therefore, Fults provides no desirability to be combined with the teachings of WinZip or 
modified to base its selection on a mode of use of a displayed object. 

For at least the reasons set forth above, WinZip and Fults cannot be combined or 
modified to teach or suggest all limitations of present claim 1 . 

There is no motivation to combine the text display system of WinZip with the 
system independence of Java, as suggested by the Examiner. Independent claim 1 teaches, 
that after the appropriate proxy component is selected, "the selected proxy component thereafter 
creates a new graphics resource component for displaying the object, such that the appearance of 
the displayed object is substantially independent of the operating system." In this manner, the 
presently claimed case provides a unique mode-switching capability that may allow two Swing 
software components (e.g., the JTextField and JPasswordField components) to alternate as 
replacements for an AWT software component (e.g., the TextField component), depending on 
the mode of use of an object (e.g., a text box). Since Swing software components do not contain 
native code, the appearance of the displayed object will be substantially independent of the 
operating system running the application program. 
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Conversely, the WinZip and Java references provide absolutely no teaching or suggestion 
for combining AWT and Swing software components within a Java application program that, 
when executed, displays an object in a manner that is independent of the operating system 
running the Java application. However, on page 3 of the Office Action mailed January 15, 2004, 
the Examiner suggests that it would have been obvious to one skilled in the art "to modify the 
text display system of WinZip to include the system independence of [the] Java [reference]." 
Though arguments were provided in the Response to that Office Action, the Examiner 
suggestions were maintained in the final Office Action mailed June 30, 2004. As previously 
noted, the Applicant respectfully disagrees with the Examiner's position that the text display 
system of WinZip can be modified to include the system independence of the Java reference. 
Reasons as to why the WinZip and Java references cannot be combined are provided below. 

As noted in the Response to the Office Action mailed January 15, 2004, the Java 
reference is merely an overview, or a brief description, of the Swing JTextField and 
JPasswordField components. Like the WinZip reference, the Java reference fails to provide any 
teaching or suggestion for combining AWT and Swing software components within a Java 
application program. Neither reference indicates that AWT and Swing software components can 
be combined in a manner that provides the presently claimed system of software components or 
the functionality thereof. Thus, the cited art fails to provide motivation for modifying the text 
display of the WinZip reference (which could reasonably include AWT components) to include 
the system independence of the Java references (which could be provided by Swing 
components). The Applicant asserts that the teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be found in the prior art, not in 
the Applicant's disclosure . In re Vaech, 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991); 
emphasis added, MPEP 2143. 

Without the benefit of Applicant's disclosure, one skilled in the art would not be 
motivated to combine the text display system of WinZip with the system independence of Java 
given the teachings of WinZip, Java, and the ordinary knowledge of one skilled in the art. 
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In addition, the Applicants disagree with the Examiner's motivation for combining the 
WinZip and Java references, which states that "[o]ne would have been motivated to make such a 
combination because this would allow people on different platforms to use similar and familiar 
interfaces." (See, e.g., Office Action, page 3; Final Office Action, page 3). Since the Java 
reference, and more specifically, the concept of Swing, already allows "people on different 
platforms to use similar and familiar interfaces," one skilled in the art would not be motivated to 
combine the system independence of Java with the WinZip application program, which is most 
likely dependent on the operating system running the WinZip application program. Thus, 
Applicant's assert that the Examiner's motivation for combining the teachings of WinZip and 
Java is insufficient. 



2. Patentability of claims 13-25 under 35 U.S.C $ 103(a) 

None of the cited art teaches, suggests or provides motivation for an application 
program configured for activating a first proxy component to dynamically generate a first 
graphical representation of an object, and upon detecting a change in the mode of use of 
the object, deactivating the first proxy component and then activating a second proxy 
component to dynamically generate a second graphical representation of an object, where 
the first and second graphical representations (one being distinct from the other) are 
substantially independent of an operating system. Independent claim 25 recites, in part: 

A computer-readable storage device, comprising. . . an application program 
running under the operating system. . . wherein the application program is adapted 
for: activating a first proxy component to dynamically generate a first graphical 
representation of the object during runtime that is substantially independent of the 
operating system; monitoring the mode of use of the object; and upon detecting a 
change in the mode of use of the object, deactivating the first proxy component 
and activating a second proxy component to dynamically generate a second 
graphical representation of the object during runtime, wherein the second 
graphical representation is substantially independent of the operating system and 
distinct from the first graphical representation. 

Independent claim 13 recites a similar limitation. In addition, claims 13 and 25 recite limitations 
similar to those recited in present claim 1 , in that they disclose various method steps that may be 
performed upon execution of the system of software components recited in present claim 1 . 
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On page 7 of the Office Action, the Examiner admits that the WinZip reference fails to 
provide teaching or suggestion for the appearance of the displayed object (i.e., the graphical 
representation of the object) being independent of the operating system . The Applicant agrees. 
However, the Applicant does not agree that the teachings of the WinZip and Java references can 
be combined to render the above limitation obvious, as is also suggested by the Examiner (e.g., 
on page 9 of the Final Office Action). As noted above, neither reference provides sufficient 
motivation that would enable one skilled in the art to make the proposed combination. The 
Examiner cannot rely on the Applicant's disclosure for providing such motivation. 

On pages 8 and 9 of the final Office Action, the Examiner admits that the WinZip and 
Java references fail to provide teaching or suggestion for using a peer component to select 
between two proxy components . The Applicant agrees. However, the Applicant does not agree 
that the teachings of the WinZip, Java, and Fults references can be combined to render the above 
limitation obvious, as is also suggested by the Examiner (e.g., on pages 9 and 10 of the Final 
Office Action). As noted above, Fults does not disclose the above limitation, and therefore, 
cannot be combined with WinZip and Java to overcome the deficiencies therein. In addition, 
none of the cited references provides sufficient motivation that would enable one skilled in the 
art to make the proposed combination. The Examiner cannot rely on the Applicant's disclosure 
for providing such motivation. 

Since the cited art cannot be combined to provide teaching or suggestion for the peer and 
proxy components recited in present claim 1 , the cited art cannot be relied upon to disclose the 
various method steps (recited in claims 13 and 25), which are performed upon execution of the 
presently claimed peer and proxy components. In other words, the cited art does not teach, nor 
can they be combined or modified to teach, an application program adapted for activating a first 
proxy component to dynamically generate a first graphical representation of an object, and upon 
detecting a change in the mode of use of the object, deactivating the first proxy component and 
then activating a second proxy component to dynamically generate a second graphical 
representation of an object, where the first and second graphical representations (one being 
distinct from the other) are substantially independent of an operating system. As described in 
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more detail below, the cited art simply fails to disclose all limitations of present claims 13 and 
25. 



For example, though the screen shots of WinZip show that a text box can display either 
masked or unmasked text, the screen shots of WinZip cannot be relied upon to teach the 
presently claimed steps of activating a first proxy component (e.g., to display an object), 
monitoring a mode of use of the object, and upon detecting a change in the mode of use of the 
object, deactivating the first proxy component and activating a second proxy component (e.g., to 
display the object in a different manner). Since the screen shots of WinZip fail to disclose the 
existence of different software components, the screen shots provide absolutely no teaching, 
suggestion or motivation for activating/deactivating different software components. The screen 
shots of WinZip also lack teaching for monitoring a mode of use of the object displayed by the 
proxy components. Instead, the manner in which text is displayed in the screen shots of WinZip 
depends on whether or not a "Mask password" checkbox is currently unchecked (WinZip — page 
3) or checked (WinZip — page 4). Therefore, if any monitoring is inherently disclosed within the 
screen shots of WinZip, such monitoring may only be used to detect a mode of use of the "Mask 
password" checkbox. By monitoring the mode of use of the "Mask password" checkbox, the 
screen shots of WinZip fail to disclose the presently claimed step of monitoring a mode of use of 
the object (e.g., the text box) displayed by the proxy components. As a consequence, the screen 
shots of WinZip fail to disclose all limitations of present claims 13 and 25. 

In addition, Fults and Java cannot be combined with WinZip to overcome the 
deficiencies therein. The Java reference, which provides a brief overview of the Swing 
JTextField and JPasswordField components, obviously fails to disclose the presently claimed 
steps of activating, monitoring and deactivating. Thus, the combination of WinZip and Java fails 
to disclose all limitations of present claims 13 and 25. Though Fults mentions that "the user may 
switch specific user interfaces (e.g. Motif to Openlook) at any time" (Fults — column 16, lines 
16-17), the switching of specific user interfaces (otherwise referred to as "style guides") does not 
provide teaching or suggestion for the presently claimed steps of activating, monitoring and 
deactivating. As noted above, the "style guides" disclosed by Fults cannot be considered a 
"mode of use of an object," as taught by the presently claimed case. Thus, Fults fails to provide 
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teaching or suggestion for monitoring a mode of use of an object, and upon detecting a change in 
the mode of use of the object, deactivating a first proxy component and activating a second 
proxy component, as recited in present claims 13 and 25. As a consequence, Fults fails to 
disclose all limitations of present claims 13 and 25, and therefore, cannot be combined with 
WinZip and/or Java to do so. 

For the foregoing reasons, Appellant asserts that independent claims 1,13, and 25, as 
well as claims dependent therefrom, are patentably distinct over WinZip, Java, and Fults. 
Contrary to the characterizations made in the various Office Actions, the cited references cannot 
be properly combined or modified to provide teaching for all limitations recited in claims 1,13, 
and 25. Accordingly, Appellants assert that a prima facie case of obviousness has not been duly 
set out and, therefore, request that this rejection be reversed. 



For the foregoing reasons, it is submitted that the Examiner's rejection of claims 1-25 
was erroneous, and reversal of the decision is respectfully requested. 



The Commissioner is authorized to charge the required fees to International Business 
Machines deposit account number 09-0447. 



Respectfully submitted, 
/Kevin L. Daffer/ 
Kevin L. Daffer 
Reg. No. 34,146 
Attorney for Appellant 

Customer No. 35617 
Date: November 15. 2006 

JMF 
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VIII. CLAIMS APPENDIX 



The present claims on appeal are as follows. 

1 . A system of software components adapted to display an object created by an application 
program running under an operating system, wherein the system of software components 
comprises: 

a first proxy component; 

a second proxy component; and 

a peer component for selecting either the first proxy component or the second proxy 

component, depending on a mode of use of the object, wherein the selection can 
be made during runtime, and wherein after the proxy component is selected, the 
selected proxy component dynamically creates a new graphics resource 
component for displaying the object, such that the appearance of the displayed 
object is substantially independent of the operating system. 

2. The system as recited in claim 1 , wherein the object is part of a graphical user interface 
associated with the application program. 

3. The system as recited in claim 1, wherein the application program controls the selection 
of the first or second proxy components by sending an indication of the mode of use to the peer 
component. 

4. The system as recited in claim 3, wherein the new graphics resource component is 
created during runtime upon selection of the first or second proxy components to replace a 
graphics resource component previously created for displaying the object. 
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5. The system as recited in claim 4, wherein the previously created graphics resource 
component is destroyed once replaced by the new graphics resource component. 

6. The system as recited in claim 4, wherein the appearance and behavior of the object 
differ depending on whether the object is displayed through the selection of the first or second 
proxy components. 

7. The system as recited in claim 1 , wherein the application program is written in Java 
programming language. 

8. The system as recited in claim 6, wherein the graphics resource components are included 
within a set of software components forming the Swing application program interface (API). 

9. The system as recited in claim 1, wherein the operating system comprises a Windows, 
Unix or OS/2 computer operating system. 

10. The system as recited in claim 8, wherein the first proxy component is configured for 
displaying the object using a Swing JTextField graphics resource component, and wherein the 
second proxy component is configured for displaying the object using a Swing JPasswordField 
graphics resource component. 

1 1 . The system as recited in claim 1 , wherein the selection of the first or second proxy 
components depends on a status of a software flag sent to the peer component as an indication of 
the mode of use. 

12. The system as recited in claim 1 1 , wherein the object is adapted to respond to text entry 
events and wherein the status of the software flag indicates whether or not a special character is 
echoed when text is entered. 
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13. A method for displaying an object created by an application program running under an 
operating system, using at least one of a system of software components, which can be invoked 
during runtime to generate a graphical representation of the object that is substantially 
independent of the operating system, the method performed by the application program and 
comprising: 

activating a first proxy component of the system of software components to dynamically 
generate a first graphical representation of the object during runtime; 

monitoring the mode of use of the object; and 

upon detecting a change in the mode of use of the object, deactivating the first proxy 
component and activating a second proxy component of the system of software 
components to dynamically generate a second graphical representation of the 
object during runtime, wherein the second graphical representation is distinct 
from the first. 

14. The method as recited in claim 13, wherein the object is part of a graphical user interface 
associated with the application program. 

15. The method as recited in claim 13, further comprising selecting the first or second 
software components by the application program. 

16. The method as recited in claim 15, further comprising creating a new graphics resource 
component for generating the second graphical representation, wherein the new graphics 
resource component is created during runtime when the second software component is selected 
by the application program. 

17. The method as recited in claim 16, further comprising destroying an old graphics 
resource component, which was previously created for generating the first graphical 
representation, when the first software component is no longer selected. 



SN 09/870,621 Supplemental Appeal Brief 



Page 24 of 2i 



18. The method as recited in claim 13, further comprising varying the appearance and 
behavior of the object, depending on whether the object is displayed during activation of the first 
or the second software components. 

19. The method as recited in claim 13, wherein the application program is written in Java 
programming language. 

20. The method as recited in claim 17, wherein the graphics resource components are 
included within a set of software components forming the Swing application program interface 
(API). 

21 . The method as recited in claim 20, wherein the first software component is configured for 
displaying the object using a Swing JTextField graphics resource component, and wherein the 
second software component is configured for displaying the object using a Swing 
JPasswordField graphics resource component. 

22. The method as recited in claim 13, wherein the operating system comprises a Windows, 
Unix or OS/2 computer operating system. 

23. The method as recited in claim 13, further comprising selecting either the first or the 
second software component, depending on a status of a software flag associated with the object. 

24. The method as recited in claim 23, further comprising the object responding to text entry 
events, and the software flag indicating whether or not a special character is echoed when text is 
entered. 

25. A computer-readable storage device, comprising: 
a windows-based operating system; 

an application program running under the operating system; 
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an object created at runtime by the application program and adapted for multiple modes 
of use by the application program, wherein the application program is adapted for: 

activating a first proxy component to dynamically generate a first graphical 
representation of the object during runtime that is substantially 
independent of the operating system; 

monitoring the mode of use of the object; and 

upon detecting a change in the mode of use of the object, deactivating the first 
component and activating a second proxy component to dynamically 
generate a second graphical representation of the object during runtime, 
wherein the second graphical representation is substantially independent 
of the operating system and distinct from the first graphical representation. 
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IX. EVIDENCE APPENDIX 

No evidence has been entered during the prosecution of the captioned case. 



SN 09/870,621 Supplemental Appeal Brief 



Page 27 of 2* 



X. RELATED PROCEEDINGS APPENDIX 



Notices of Appeal have been filed for the following applications, which share a common 
specification with the application currently on appeal. 



09/870,613: Notice of Appeal filed 2/07/05: 
09/870,615: Notice of Appeal filed 9/14/04: 
09/870,620: Notice of Appeal filed 12/7/04: 
09/870,621: Notice of Appeal filed 9/24/04: 
09/870,622: Notice of Appeal filed 8/24/04: 
09/870,624: Notice of Appeal filed 5/23/05: 



Appeal Brief filed April 7, 2005. 
Appeal Brief filed November 9, 2004. 
Appeal Brief filed February 7, 2005. 
Appeal Brief filed November 23, 2004. 
Appeal Brief filed October 25, 2004. 
Appeal Brief filed July 25, 2005. 



However, because dissimilar art is cited in the present application and the above-mentioned 
related applications, Appellants do not believe that the outcome of this appeal will have any 
bearing on the Board's decision on the related appeals. No other appeals or interferences are 
known which would directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 
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